Phasendokumente
◦
Überblick ◦
?
Man kann ein Softwareprojekt in Phasen einteilen und für jede Phase charakteristische Dokumente definieren. Wir dokumentieren die Entwicklung von TESTS in den folgenden Phasen:
Das Risiko einer Phaseneinteilung ist das "Wasserfall"-Konzept der Softwareentwicklung: Jede Entwicklungsphase muss abgeschlossen sein, bevor die nächste Phase beginnt. Die Praxis entspricht allerdings dem folgenden Vorgehen: Phasen überlappen sich, und der typische Entwickler kehrt laufend zu früheren Phasen zurück, um deren Dokumente zu revidieren. Man nennt diese Konzeption der Softwareentwicklung "zyklisch", "iterativ" oder "explorativ".
Der blosse Schreibtischentwurf einer Anwendung, insbesondere ihrer Benutzerschnittstelle, riskiert an den Bedürfnissen der Anwender vorbeizugehen. Zum einen ist es sowohl für künftige Benutzer als auch für Entwickler schwierig, eine Feinspezifikation und einen Feinentwurf ohne Demonstration der wichtigsten Eigenschaften zu erstellen. Zum anderen endet der Entwicklungsprozess nie, weil stets Verbesserungen möglich sind. Oft setzt man deshalb eine erste Annäherung an die Detailspezifikation schon bald in einen Prototyp um. Dieser erste Prototyp ist Anlass für Diskussionen unter Entwicklern und Anwendern. Nach einer Verfeinerung der Spezifikation entsteht ein zweiter Prototyp, der den Vorstellungen der Auftraggeber und Anwender besser entspricht. Dieses explorative Vorgehen wird solange wiederholt, bis die Anwenderbedürfnisse befriedigt oder die gesetzte Entwicklungsdauer erreicht ist. Man nennt diese Art der Softwareentwicklung explorativ oder zyklisch.
Die explorative Anwendungsentwicklung darf allerdings nicht dazu führen, dass 'Versuch und Irrtum' den überlegten Top Down-Entwurf verdrängt. Sorgfältige Überlegungen zur Spezfikation, zur Modularisierung und zur Algorithmisierung verhindern Fehler in den späteren Phasen. Vorschnelle Implementationsentscheidungen lassen sich meist nur mit grossem Zeitaufwand korrigieren. Fehler in der 'Paper and Pencil'-Phase lassen sich hingegen leichter verbessern.
Oft ist es nicht nötig, einen vollständigen Prototyp zu erstellen. In Access genügt es zum Beispiel den Dialogentwurf (Formulare und Berichte) anzudeuten, um dem Auftraggeber oder dem künftigen Anwender einen Eindruck von der Benutzeroberfläche zu geben. Investieren Sie aber nicht zu viel Zeit in die Form von Steuerelemente und die Navigation, falls die Benutzeroberfläche noch nicht endgültig ist. Konzentrieren Sie sich ausserdem auf die Minimalspezifikation.